The present invention relates to a bridging device and its method of access. More particularly, the present invention may be related to accessing descriptor and/or configuration information of a bridge-chip using a mass storage class driver protocol.
The Universal Serial Bus specification (e.g., version 1.0 or 2.0), available from the American National Standards Institute (ANSI), hereby incorporated by reference, establishes architectures and standards for communicating between a computer and peripheral(s) over a serial transmission interconnect. Examples of peripherals may include, e.g., keyboards, mouse, monitor, printer, scanner and/or removable hard drives. The communications of the USB interface may be isochronous or asynchronous. The USB interface may also distribute power to the peripherals.
Some mass storage devices may have an interface that is different from the USB standard. For example, the ATA/ATAPI-6, NCITS Draft specification (e.g., T13/1410D of Revision 3A of Dec. 14, 2001) available from ANSI and hereby incorporated by reference, establishes protocols of an ATA (Advanced Technology Attachment) or ATAPI (ATA packet Interface) type interface. The ATA/ATAPI specification addresses how to pass commands to a storage device and how these commands might be interpreted.
ATA type storage devices may include, for example, hard drives or removable media drives—e.g., disk drives, flash memory card interfaces, micro-drives and the like. Strict ATA type devices may not support packet-type transfers. ATAPI type storage devices, on the other hand, may support packet interfacing. Such devices may include, for example, CD-ROMs, CD-Recordable, CD-RW, DVD, tape drives, super-floppy drives, some ZIP drives and the like.
In some data processing systems, a bridge-chip may translate a protocol of one bus to that of another. For example, a bridge-chip may receive USB communications from a host and may translate the USB communications into ATA/ATAPI commands for accessing an ATA or ATAPI type storage. The bridge-chip might also serve to translate in a reverse direction from the ATA/ATAPI interface to the USB.
A logical pipe may be preconfigured during a USB device initialization procedure between a master and slave. When a USB device, e.g., a mouse or keyboard, is initially attached to the USB bus and powered-up, the device may communicate configuration, status and control information. The host may establish a functionality and unique USB address for the newly attached USB device and may obtain the USB “descriptor” and “configuration” information of the attached USB device.
The mass storage class devices handle large amounts of data. For example, a scanner may generate a large data file, which may then need to be transferred to a memory or other subsystem. Likewise, the memory may contain a large data file, which may then need to be transferred to a processor or directly to a printer. When transferring the large data files, the mass storage devices may use bulk transfer protocols to assist in reliability of the bulk transfers.
Generally, referencing FIGS. 1–2, a host 10 may include an Operating System (OS) 200 capable of accessing a mass storage device 14 (e.g., of an ATA/ATAPI type device) over a USB bus 16. The host may comprise an OS Basic Input/Output System (BIOS) with a library of routines available to launch commands or transport applications from its controller to an end device such as a mass storage device 14 (of FIG. 1). Likewise, the mass storage device may have software (e.g., client software) 212, which may help the host coordinate communications.
In FIG. 2, an actual physical link 224 is represented by a solid line. Dashed lines 216 and 220 may be representative of logical communication paths to respective levels of an external device (not shown).
Conventionally, USB descriptor and/or configuration information may be obtained from a bridge chip during configuration of the USB bus and using protocols of the USB specification. Further referencing FIG. 1, bridge-chip 12 may include chip configuration data that is specific to the IC. The chip configuration data may include information of, e.g., power requirements, mode of operation, particular vendor lot number, options being implemented, programmability, etc., that may be specific to the bridge-chip. The bridge-chip may access the chip configuration data and the USB descriptor data through a memory device, such as, e.g., an on-chip ROM, on-chip RAM, external EEPROM, etc.
Conventionally, referencing FIG. 2, the USB descriptor data may be accessed by way of a USB driver 218 of host 200. The information may be obtained from the bridge-chip using the conventional USB-Device-Request, e.g., GET_DESCRIPTOR, through a USB control pipe 220. The chip configuration data of the bridge-chip conventionally would be accessed by issuing Vendor Specific (CFG-READ, CFG_LOAD) USB Device Requests through the USB control pipe 220. However, accessing this bridge-chip configuration and descriptor data through use of USB Device Requests conventionally required a vendor specific driver 214 that might be provided with the client software. The vendor specific driver 214 might then know how to issue requests for the bridge-chip's information.
It is recognized herein, that there may be advantages in allowing access of the bridge-chip's configuration and descriptor data without need of a vendor specific driver.